Skip to content

Refactor: AbstractShadowFilter reduce object allocations #2516

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

capdevon
Copy link
Contributor

@capdevon capdevon commented Jun 23, 2025

Refactor AbstractShadowFilter: Remove Unused Serialization and Legacy Fields

  • Removed unused imports and legacy serialization methods (write/read), simplifying the class.
  • Cleaned up and clarified Javadoc comments for constructors and author attribution.
  • Replaced legacy temporary variables with final temp fields for matrix and vector operations, improving consistency.
  • Minor improvements in naming and parameter descriptions for clarity and maintainability.

This refactor streamlines the code, reduces clutter, and adheres to modern coding practices without affecting functionality.

*/
public abstract class AbstractShadowFilter<T extends AbstractShadowRenderer> extends Filter implements Cloneable, JmeCloneable {
public abstract class AbstractShadowFilter<T extends AbstractShadowRenderer> extends Filter implements JmeCloneable {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why remove Cloneable? (Why was it here in the first place?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The JmeCloneable interface already extends java.lang.Cloneable. Therefore, the explicit extension is redundant and its removal simplifies the code without altering its behavior. Therefore, what checks have you already performed that led you to raise this question?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes good point. No objection to removing it then

@richardTingle
Copy link
Member

Looks good to me

@riccardobl
Copy link
Member

Thanks for this PR and good find.

I have only one question:
The engine usually uses TempVars in this case, is there any big downside in using that to be consistent with the rest of the code?

@capdevon
Copy link
Contributor Author

capdevon commented Jul 11, 2025

I have only one question:
The engine usually uses TempVars in this case, is there any big downside in using that to be consistent with the rest of the code?

Done! Thank you for your feedback guys.

Copy link

🖼️ Screenshot tests have failed.

The purpose of these tests is to ensure that changes introduced in this PR don't break visual features. They are visual unit tests.

📄 Where to find the report:

  • Go to the (failed run) > Summary > Artifacts > screenshot-test-report
  • Download the zip and open jme3-screenshot-tests/build/reports/ScreenshotDiffReport.html

⚠️ If you didn't expect to change anything visual:
Fix your changes so the screenshot tests pass.

If you did mean to change things:
Review the replacement images in jme3-screenshot-tests/build/changed-images to make sure they really are improvements and then replace and commit the replacement images at jme3-screenshot-tests/src/test/resources.

If you are creating entirely new tests:
Find the new images in jme3-screenshot-tests/build/changed-images and commit the new images at jme3-screenshot-tests/src/test/resources.

Note; it is very important that the committed reference images are created on the build pipeline, locally created images are not reliable. Similarly tests will fail locally but you can look at the report to check they are "visually similar".

See https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-screenshot-tests/README.md for more information

Contact @richardTingle (aka richtea) for guidance if required

@richardTingle
Copy link
Member

Weird, I can't see anything in your commit that would have broken shadows but the shadow has disappeared from the screenshot

image

@capdevon
Copy link
Contributor Author

capdevon commented Jul 11, 2025

I think I understand the problem. The temp variables passed to the material must be permanent, not volatile. In this case, TempVars cannot be used, and persistent class variables must be used as before.

@yaRnMcDonuts yaRnMcDonuts merged commit 3613bfd into jMonkeyEngine:master Jul 12, 2025
16 checks passed
@capdevon capdevon deleted the capdevon-AbstractShadowFilter branch July 12, 2025 22:30
@yaRnMcDonuts yaRnMcDonuts added this to the v3.9.0 milestone Jul 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants